Implementing Bivariate Bicycle Codes using 2BGA as the parent via Hecke's Group Algebra #399
Conversation
Fe-r-oz
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #399 +/- ##
==========================================
+ Coverage 83.00% 83.07% +0.06%
==========================================
Files 71 71
Lines 4560 4560
==========================================
+ Hits 3785 3788 +3
+ Misses 775 772 -3 ☔ View full report in Codecov by Sentry. |
Fe-r-oz
changed the title
|
This PR is ready for review @Krastanov, Thank you! Tasks Completed:
After this PR is finished, I will add a canonical equivalence test to #372 using the graph TD
subgraph A[LP]
B[2BGA]
subgraph B[2BGA]
C[BB]
end
end
Edit: Tommy is introducing group algebras with sparse representation here: thofma/Hecke.jl#1655. I will add this functionality when available! P.S. After review, Tommy decided that sparse representations for GAs should be the default, similar to those in MAGMA, in Hecke v0.34.6, thereby eliminating the need for users to introduce them manually. |
|
|
||
| julia> x, y = gens(GA); | ||
|
|
||
| julia> A = [x^3 , y^10 , y^17]; |
There was a problem hiding this comment.
why write this down as [x^3 , y^10 , y^17] instead of x^3 + y^10 + y^17 and use directly two_block_group_algebra_codes? What is the advantage of the list notation?
There was a problem hiding this comment.
You are right. For regular abelian groups via Hecke's group algebra, we can use the non-list notation.
The advantage of list notation is when using finitely presented groups from Oscar with specific group presentations which is not related to this PR.
julia> b_elts = 1 + s + r^6 + s^3 * r + s * r^7 + s^3 * r^5;
ERROR: MethodError: no method matching +(::Int64, ::FPGroupElem)
The function `+` exists, but no method is defined for this combination of argument types.
Closest candidates are:
+(::Any, ::Any, ::Any, ::Any...)
@ Base operators.jl:596
+(::Oscar.StraightLinePrograms.Lazy, ::Any)
@ Oscar ~/.julia/packages/Oscar/2lR8w/src/StraightLinePrograms/lazy.jl:98
+(::Any, ::Oscar.StraightLinePrograms.Lazy)
@ Oscar ~/.julia/packages/Oscar/2lR8w/src/StraightLinePrograms/lazy.jl:99
...
Stacktrace:
[1] +(::Int64, ::FPGroupElem, ::FPGroupElem, ::FPGroupElem, ::FPGroupElem, ::FPGroupElem)
@ Base ./operators.jl:596
[2] top-level scope
@ REPL[9]:1
27d9897 to
d4a9ef0
Compare
| function bivariate_bicycle_codes(A::GroupAlgebraElem, B::GroupAlgebraElem) | ||
| c = two_block_group_algebra_codes(A,B) | ||
| return c | ||
| end |
There was a problem hiding this comment.
a followup on my previous question: if now this is all that is needed, why even have a separate function, why not just have two_block_group_algebra_codes and add this as yet another example in the docstring, similar to the other PRs you have on this family of codes
I might be wrong, maybe there is some benefit to keeping a separate function for this class of codes, but such a separate function would need something "special" when compared to two_block_group_algebra_codes
There was a problem hiding this comment.
Thank you for these suggestions. I applied the Oscar.FPGroup list notation that Tommy introduced for specific stuff and applied it to Hecke out of curiosity for no particular reason.
|
Thank you for your suggestions. The PR is ready for review! By the way, your 2BGA enhancement made the group algebra elements |
This PR implements the Bivaraite Bicycle code with parent being 2BGA. This construction is given by ECC Zoo: https://errorcorrectionzoo.org/c/qcga. This is canonically equivalent to #372. This is the third construction method for these codes.